Signaling events in workflow management systems

ABSTRACT

The present invention provides a computerized method for determining an addressee of a signaling request within a Workflow Management System or a computer system with comparable functionality (WFMS). Upon receiving a signaling request, which is providing a set of signal data elements, the current invention avoids the requirement that the signal data elements comprise any explicit specification of an addressee of said signaling request. To determine whether an event-activity of a process-instance being the instance of a process-model of a business-process is the potential addressee of the signaling request it is suggested to determine, whether the process-model comprises an event-identification-specification. This event-identification-specification according to the current invention is involving a subset of the signal data elements. Evaluating the event-identification-specification allows to indirectly decide if the event-activity is the addressee of the signaling request.

1. BACKGROUND OF THE INVENTION 1.1 Field of the Invention

[0001] The present invention relates to means and a method for improvingthe robustness and ease-of-use of Workflow-Management-Systems or acomputer system with comparable functionality (WEMS) related to thesignaling of events.

1.2 Description and Disadvantages of Prior Art

[0002] A new area of technology with increasing importance is the domainof Workflow-Management-Systems (WFMS). WFMS support the modeling andexecution of business processes. Business processes executed within aWEMS environment control who will perform which piece of work of anetwork of pieces of work and which resources are exploited for thiswork. The individual pieces of work might be distributed across amultitude of different computer systems connected by some type ofnetwork.

[0003] The product “IBM MQSeries Workflow” (previously called IBMFlowMark) represents such a typical modern, sophisticated, and powerfulworkflow management system. It supports the modeling of businessprocesses as a network of activities. This network of activities, theprocess model, is constructed as a directed, acyclic, weighted, coloredgraph. The nodes of the graph represent the activities, which areperformed. The edges of the graph, the control connectors, describe thepotential sequence of execution of the activities. Definition of theprocess graph is via IBM MQSeries Workflow's Flow Definition Language(FDL) or via the built-in graphical editor.

[0004] The runtime component of the Workflow-Management-System uses saidprocess model as a template to create process instances. Each processinstance is associated with a set of values, typically called thecontext. Said values are either supplied by the requestor of the processinstance via the appropriate request or retrieved by programs thatimplement the various activities or are the result of the executionhistory of a certain process instance. The context is unique to acertain process instance. A particular important piece of informationwithin said context is the process instance identifier that uniquelyidentifies a process instance. It should be noted that typically processinstance identifiers are only unique within the set of process instancesthat are derived from a particular process model.

[0005] Particular important types of activities are event activities. Anevent activity provides the capability to have a process instancewaiting until signaled. The signal, or in other words the event, may becreated within the WFMS but typically will have its source in theoutside of the workflow management system. Upon receiving said signal,the workflow management system stores the supplied information ascontext information (in this case into the output container of the eventactivity) and continues navigation.

[0006] Signaling the event is done via an appropriate signal request tothe workflow management system. Said signal request may be created by aprogram exploiting the application-programming interface offered by theworkflow management system or by sending an appropriate workflowmanagement system defined message to the workflow management system thatcan typically carry such a signal request. Independently of howsignaling is done, the signaling request must contain the appropriateprocess instance identifier of the process instance in which the eventis waiting as well as the identification of the event. This informationis necessary so that the workflow management system can locate thecorrect process instance and the correct event within the process model.If the issuer of the signaling request does not know the eventidentification or even does not know the process instance identifier,the issuer must obtain this information. To facilitate this the workflowmanagement provides query capabilities that allow the issuer to querythe input container of the-event activity. It is the responsibility ofthe process modeler to make sure that the input container of the eventactivity contains the appropriate values from which the process instanceidentification can be derived.

[0007] This state-of-the-art approach has several deficiencies, inparticular when an event is signaled by sending a message to theworkflow management system:

[0008] The signaler of the event must indicate to the workflowmanagement system that the request is for signaling an event; that meansthe requester must follow the message structure defined by the workflowmanagement system. This structure typically mandates to have certainindicators, such as the command that the message represents, in certainplaces of the message; for example the text string signal as the firstfield of the message. This mandates that an existing message-orientedsignaler program must be adapted when the signal should now be processedby a workflow management system; an approach that is not always possibleto implement. Another approach to overcome this situation is the usageof a translation program that translates the signaler's original messageinto the workflow management specific message; an approach thatincreases not only the complexity of the overall system (makingmaintenance and system management much more complicated) but alsodecreases performance for generating a signal.

[0009] The signaler must maintain the process instance identifier of thetarget process instance. If this is not possible, the signaler mustobtain appropriate information (data in the input container of theevent) from the workflow management system. This requires that thesignaler already knows the name of the event so that it can set up theappropriate query to the workflow management system. This has thedisadvantage that every change made to the process model such aschanging the name of the event requires re-programming on the signaler'spart (such as adapting the new name of the event).

[0010] The signaler must know the name (according to the nomenclature ofthe WEMS) of the event even if it knows the process instance identifier.Knowing the name includes knowing to some extent the structure of theprocess model; for example the process model could use the same namemultiple times within the same process model, a situation that caneasily arise when one synthesizes more, complex process models fromsimpler process models.

[0011] The above listed deficiencies make it obvious that the currentstate of the art enforces a tight coupling between the signaler of anevent and the workflow management system manifested by the informationthat the signaler must maintain about information that the workflowmanagement system maintains. This situation is quite undesirable for thereasons outlined above. It should be possible to specify in the workflowmanagement system all information necessary to process an almostarbitrary message for signaling an event. Further it should be possiblefor an arbitrary signaling of events to send signaling events to a WFMSwithout said signal being adapted to WEMS requirements. The arbitrarysignaler should allowed to be unaware of the concrete nature of theconsumer (that is the addressee) of the signaling requests. Then it ispossible that the signaler can be developed independently from theconsumer of the signaling request.

[0012] The weakness of the state-of-the-art approaches with respect tothis problem area becomes even more distinct if one thinks of typicalInternet scenarios commonly summarized by terms like C2B(Consumer-to-Business) or B2B (Business-to-Consumer) business processes.In these scenarios, it is obvious that the tight coupling of signaler tothe workflow management system is not desirable at all.

1.2 OBJECTIVE OF THE INVENTION

[0013] The invention is based on the objective to eliminate the need forevent signalers to maintain information that is needed to locate theappropriate event in the appropriate process instance waiting fornotification of said event.

2. SUMMARY AND ADVANTAGES OF THE INVENTION

[0014] The objectives of the invention are solved by the independentclaims. Further advantageous arrangements and embodiments of theinvention are set forth in the respective subclaims.

[0015] The present invention provides a computerized method fordetermining an addressee of a signaling request within a WorkflowManagement System or a computer system with comparable functionality(WFMS).

[0016] Upon receiving a signaling request, which is providing a set ofsignal data elements, the current invention avoids the requirement thatthe signal data elements comprise any explicit specification of anaddressee of said signaling request.

[0017] To determine whether a particular event-activity of aprocess-instance being the instance of a process-model of abusiness-process is the potential addressee of the signaling request itis suggested to determine, whether the process-model comprises anevent-identification-specification. Thisevent-identification-specification according to the current inventioninvolves a subset of the signal data elements. Evaluating theevent-identification-specification allows to indirectly decide if theevent-activity is the addressee of the signaling request.

[0018] The suggested teaching avoids all of above-mentioneddeficiencies. Relieving the signaler of a signaling request fromspecifying a certain addressee based on the suggested approach offersthe further advantage that multiple addressees might exist for a singlesignaling messaging.

3. BRIEF DESCRIPTION OF THE DRAWINGS

[0019]FIG. 1 shows an example of a process model represented by aprocess graph.

[0020]FIG. 2 illustrates the implementation of signatures of activitiesas input and out containers and the movement of data from one activityto another activity via data connectors

[0021]FIG. 3 illustrates the structure of an event activity that whenactivated waits for a message to be processed.

[0022]FIG. 4 illustrates the definition of a message signaling an eventusing an XML schema definition for describing the contents of themessage.

[0023]FIG. 5 visualizes the details of the necessary specificationsusing the Flow Definition Language of MQSeries Workflow.

[0024]FIG. 6 illustrates an alternate method of determining thestructure of a message that signals an event.

[0025]FIG. 7 illustrates an alternate method of identifying the eventthat is the target of a signaling message.

4. DESCRIPTION OF THE PREFERRED EMBODIMENT

[0026] In the drawings and specification there has been set forth apreferred embodiment of the invention and, although specific terms areused, the description thus given uses terminology in a generic anddescriptive sense only and not for purposes of limitation. It will,however, be evident that various modifications and changes may be madethereto without departing from the broader spirit and scope of theinvention as set forth in the appended claims.

[0027] The present invention can be realized in hardware, software, or acombination of hardware and software. Any kind of computer system—orother apparatus adapted for carrying out the methods described herein—issuited. A typical combination of hardware and software could be ageneral-purpose computer system with a computer program that, when beingloaded and executed, controls the computer system such that it carriesout the methods described herein. The present invention can also beembedded in a computer program product, which comprises all the featuresenabling the implementation of the methods described herein, andwhich—when being loaded in a computer system—is able to carry out thesemethods.

[0028] Computer program means or computer program in the present contextmean any expression, in any language, code or notation, of a set ofinstructions intended to cause a system having an information processingcapability to perform a particular function either directly or aftereither or both of the following a) conversion to another language, codeor notation; b) reproduction in a different material form.

[0029] The current invention is illustrated based on IBM's “MQSeriesWorkflow” workflow management system. Of course any other WFMS could beused instead. Furthermore the current teaching applies also to any othertype of system, which offers WFMS functionalities not as a separate WFMSbut within some other type of system.

[0030] According to the current teaching it is advantageous if the WFMSengine is the processing entity to determine the addressee(s) of anysignaling request based on the data elements provided by the signaler.But of course, the current invention can be applied in other scenarioswherein the processing entity of the request for signaling an event isnot the WFMS engine itself some other entity.

4.1 Introduction

[0031] The following is a short outline on the basic concepts of aworkflow management system based on IBM's “MQSeries Workflow” WFMS:

[0032] From an enterprise point of view the management of businessprocesses is becoming increasingly important: business processes orprocess for short control which piece of work will be performed by whomand which resources are exploited for this work, i.e. a business processdescribes how an enterprise will achieve its business goals. A WFMS maysupport both, the modeling of business processes and their execution.

[0033] Modeling of a business process as a syntactical unit in a waythat is directly supported by a software system is extremely desirable.Moreover, the software system can also work as an interpreter basicallygetting as input such a model: The model, called a process model orworkflow model, can then be instantiated and the individual sequence ofwork steps depending on the context of the instantiation of the modelcan be determined. Such a model of a business process can be perceivedas a template for a class of similar processes performed within anenterprise; it is a schema describing all possible execution variants ofa particular kind of business process. An instance of such a model andits interpretation represents an individual process, i.e. a concrete,context dependent execution of a variant prescribed by the model. A WEMSfacilitates the management of business processes. It provides a means todescribe models of business processes (buildtime) and it drives businessprocesses based on an associated model (runtime). The meta model ofIBM's WEMS MQSeries Workflow, i.e. the syntactical elements provided fordescribing business process models, and the meaning and interpretationof these syntactical elements, is described next.

[0034] A process model is a complete representation of a process,comprising a process diagram and the settings that define the logicbehind the components of the diagram. Important components of anMQSeries Workflow process model are:

[0035] Processes

[0036] Activities

[0037] Blocks

[0038] Control Flows

[0039] Connectors

[0040] Data Containers

[0041] Data Structures

[0042] Conditions

[0043] Programs

[0044] Staff

[0045] Not all of these elements will be described below.

[0046] Activities are the fundamental elements of the meta model. Anactivity represents a business action that is from a certain perspectivea semantic entity of its own.

[0047] An MQSeries Workflow process model consists of the followingtypes of activities:

[0048] Program activity: Has a program assigned to perform the activity.The program is invoked when the activity is started. In a fullyautomated workflow, the program performs the activity without humanintervention. Otherwise, the user must start the activity by selectingit from a runtime work list. Output from the program can be used in theexit condition for the program activity and for the transitionconditions to other activities.

[0049] Process activity: Has a (sub-)process assigned to perform theactivity. The process is invoked when the activity is started. A processactivity represents a way to reuse a set of activities that are commonto different processes. Output from the process, can be used in the exitcondition for the process activity and for the transition conditions toother activities.

[0050] The flow of control, i.e. the control flow through a runningprocess determines the sequence in which activities are executed. TheMQSeries Workflow workflow manager navigates a path through the processthat is determined by the evaluation to TRUE of start conditions, exitconditions, and transition conditions.

[0051] Connectors link activities in a process model. Using connectors,one defines the sequence of activities and the transmission of databetween activities. Since activities might not be executed arbitrarilythey are bound together via control connectors. A control connectormight be perceived as a directed edge between two activities; theactivity at the connector's end point cannot start before the activityat the start point of the connector has finished (successfully). Controlconnectors model thus the potential flow of control within a businessprocess model. Default connectors specify where control should flow whenthe transition condition of no other control connector leaving anactivity evaluates to TRUE. Default connectors enable the workflow modelto cope with exceptional events. Data connectors specify the flow ofdata in a workflow model. A data connector originates from an activityor a block, and has an activity or a block as its target. One canspecify that output data is to go to one target or to multiple targets.A target can have more than one incoming data connector.

[0052] Process definition includes modeling of activities, controlconnectors between the activities, input/output container, and dataconnectors. A process is represented as a directed acyclic graph withthe activities as nodes and the control/data connectors as the edges ofthe graph. The graph is manipulated via a built-in graphic editor. Thedata containers are specified as named data structures. These datastructures themselves are specified via the DataStructureDefinitionfacility. Program activities are implemented through programs. Theprograms are registered via the Program Definition facility. Blockscontain the same constructs as processes, such as activities, controlconnectors etc. They are however not named and have their own exitcondition. If the exit condition is not met, the block is started again.The block thus implements a Do Until construct. Process activities areimplemented as processes. These subprocesses are defined separately asregular, named processes with all its usual properties. Processactivities offer great flexibility for process definition. It not onlyallows to construct a process through permanent refinement of activitiesinto program and process' activities (top-down), but also to build aprocess out of a set of existing processes (bottom-up).

[0053] All programs, which implement program activities, are defined viathe Program Registration Facility. Registered for each program is thename of the program, its location, and the invocation string. Theinvocation string consists of the program name and the command stringpassed to the program.

[0054] As an example of such a process model FIG. 1 shows schematicallythe structure of such a process graph. Activities (A1 up to A5) arerepresented as named circles; the name typically describes the purposeof the activity. Activities come in various flavors to address thedifferent tasks that may need to be performed. They may have differentactivity implementations to meet these diverse needs. Program activitiesare performed by an assigned program, process activities like forinstance 100 are performed by another process 101, and blocks like forinstance 102 implement a macro 103 with a built-in do-until loop.Control connectors p12, p13, p24, p35, p45 are represented as arrows;the head of the arrow describes the direction in which the flow ofcontrol is moving through the process. The activity where the controlconnector starts is called the source activity; where it ends is calledthe target activity. When more than one control connector leaves anactivity, this indicates potentially parallel work.

4.2 Containers and Data Connectors

[0055]FIG. 2 shows the two activities A 200 and B 210, Which may be partof a more complex process model. Both activities A 200 and B 210 have aninput container 220, 240 associated with them; activity A 200 has alsoan output container 230 associated with. In a fundamental alterationaccording to the current invention the input and output container of anactivity can be viewed conceptually as the signature of the activity.The activity obtains data necessary for its execution from the inputcontainer and writes data that it produces and that is needed for otheractivities into the output container. As with signatures, the containersof an activity are only available to the activity; that means they areonly available locally. For example, the input container 220 and theoutput container 230 are only available to the associated activity A200. Thus, if activity B 210 needs data, for example, from the outputcontainer 230 of the activity A 200, this data must be copied from theoutput container 230 of the activity A 200 to the input container 240 ofthe activity B 210.

[0056] For the purpose of copying data from one of the activities toanother activity, a data connector 260 is provided which is depicted inFIG. 2 as a dashed arrow. The data connector 260 of FIG. 2 indicatesthat all or parts of the output container 230 of the activity A 200 hasto be copied to the input container 240 of the activity B 210.

[0057] The output container of one activity and the input container ofanother activity, however, generally have different data structures, forexample containing different data fields. Therefore, a container map 250is provided in FIG. 2 which defines which data fields of the outputcontainer 230 of the activity A 200 are copied into which data fields ofthe input container 240 of the activity B 210. The container map 250also specifies if a transformation of the data has to be performed bythe workflow management system before the data is copied e.g. into theinput container 240 of the activity B 210.

4.3 Event Activities

[0058] Event activities are another type of activities that workflowmanagement systems support. They provide the capability to have aprocess instance wait until the event is signaled for instance fromoutside the workflow management system upon. Upon receiving the signal,the workflow management system processes the request and continuesnavigation. An event activity has most of the properties program andprocess activities. Is associated with an input and an output container.It can be source and the target of control connectors as well as thesource and target of data connectors. It has a start condition, and adeadline can be specified for it.

[0059]FIG. 3 illustrates this schematically showing portion 301 of somemore complex process model. An event activity 300 goes into the waitingstate as soon the control connector 360 enters the event activity. If inrealization of a process model the event activity has no incomingcontrol connector, the event activity goes into the waiting state assoon as the process instance is created. The event activity remains inthis state until the event is signaled. Some client 310 is issuing anappropriate request 350 to the workflow management system signaling theevent the event activity 300 is waiting for. This request must (1)identify the appropriate event (2) in the appropriate process instanceas addressee. Additionally the event signal may supply data that isstored in the output container 320, so that information provided by theevent signaler can be made available to the process instance. When theevent is signaled correctly, navigation continues. Further details onevent activities can be found in Leymann/Roller, Production Workflow:Concepts and Techniques, Prentice Hall, N.J. ISBN and in U.S. Patent No.U.S. 6,065,009 Events as Activities in Process Models of WorkflowManagement Systems.

4.4 Defining Messages via XML

[0060]FIG. 4 shows the definition of a message via XML Schema Definition(see http://www.w3.org for details about XML and XML schema). Thepurpose of the message is to signal an event to the event activitydefined in FIG. 5. The keyword complexType 400 starts the definition ofa user-defined XML structure. The name of the structure is SignalMessage410. The structure consists of a set of elements 420, with an elementname 430 and a data type 440 of said element.

4.5 Processing the Signaling of an Event

[0061]FIG. 5 illustrates how the present invention can beimplemented/specified using the Flow Definition Language (FDL) ofMQSeries Workflow, a state-of-the-art Workflow-Management-System sold bythe applicant. FDL is used as an example only; any other way ofspecifying the signaling of events can be used. The underlying metamodel is also for illustration only; other meta models can be usedinstead.

[0062] The important teaching of the current invention is to provide atechnology allowing an arbitrary signaler of an event to be completelyunaware of the addressee of a signaling request; that means the concreteprocess instance waiting for said event. This releases the signaler frommaintaining the process instance identifier of the awaiting concreteprocess instance and from maintaining the identifier of event activitywithin the corresponding process model.

[0063] Is a fundamental observation of the current invention that thedata elements or a subset of the data elements provided by the signalerwithin the signaling request can be exploited by the WFMS itself touniquely identify the concrete process instance (or process instances)and/or the concrete event activity (or event activities) being theaddressee(s) of the event.

[0064] To enable the WFMS to perform this identification task it issuggested to enhance the process model comprising an event activity withspecifications defining that set of (one or multiple) data elementsprovided by the signaling request to be used to identify a certainprocess instance of said process model and said event activity asaddressee. Once the signaling request is received by the WFMS, the WFMSknowing the process model would exploit these predefined eventidentification specifications and the concrete data elements providedwith the signaling request to determine the concrete addressee of theevent.

[0065] The example illustrates the definition of an event activity thatexploits the present invention.

[0066] The DATASTRUCTURE definition 500 identifies a data structure withthe name SignalMessage 501. The data structure references (via the XMLkeyword) 502 an XML schema SignalMessage 503 (this is the XML schemadefined in FIG. 4). This data structure defines the structure of themessage that is accepted a signal that posts the event activity 520.

[0067] The DATASTRUCTURE definition 510 identifies a data structure withthe name EventOutput. The data structure contains a field AmountOfferedof type INTEGER 512. This data structure is used for the outputcontainer of the event activity 520; the field AmountOffered is intendedas the target for the appropriate field supplied in the signalingmessage.

[0068] The event activity is defined via the EVENT_ACTIVITY keyword 520;the name of the event activity is ReceiveOffer 522. The output containerof the event activity is defined via the OUTPUT keyword, whichidentifies the data structure EventOutput 524 as the structure for theoutput container.

[0069] The keyword SIGNAL 540 identifies all properties associated withsignaling the event; in specific the event identification specificationsproposed by the current invention are comprised within this section.Within the current example it identifies that the data structureSignalMessage 526 represents the structure of the message signaling theevent.

[0070] The keyword MESSAGE_IDENTIFICATION 536 is used to indicate to theworkflow management system how the structure of the message should bedetermined; that is defining the layout of the message. The parameterXML_SCHEMA 528 indicates that the message provided XML schema nameshould be used (this is typical for XML messages as it is desireable tobe able to use an XML parser for parsing the message). Other possibleparameter values of the MESSAGE_IDENTIFICATION parameter will bediscussed below. If the signaling message is of the specified XMLschema, the workflow management system takes this message as a potentialsignaling message for this ReceiveOffer activity. That means, if thesignaling message is of XML schema SignalMessage, the signaling messageis a candidate for a signaling message for the event activityReceiveOffer 522.

[0071] The keyword PROCESS_INSTANCE 542 identifies the field(s) in thesignaling message that should be used to identify the process instance.In the example, the field ContractId 530 from the XML message is used.In general the process instance can be identified by any arbitrarycomplex Boolean expression involving values of data elements within thesignaling message and data elements from the process instance's context.

[0072] The keyword TARGET_IDENTIFICATION 544 is used to define anexpression 532 that when it evaluates to true, the signaling message istargeted towards the event activity. Thus this keyword allowsidentifying the concrete activity within the process model the event isto be signaled to by the WFMS. The expression is constructed by usingone or more fields in the signaling message. In the example, thesignaling message is targeted for this activity, if the field ActionIdin the signaling message contains the text string ReceiveOffer.

[0073] The MAP keyword 546 provides for the capability of mapping fieldsfrom the signaling message to the activity output container. In theexample, it copies the field AmountOffered from the signaling message tothe output container. Other possibilities are the copying of fields ofthe signaling message to a global/key container (see Leymann/Roller:Production Workflow: Concepts and Techniques, Prentice Hall, 2000 fordetails).

[0074] Another possibility to identify the structure of a signalingmessage is illustrated in FIG. 6. It defines an expression, that when itevaluates to true, the signaling message has the structure specified asthe signaling message structure. That means when the field messageId 610contains the value 512, the signaling message has the structure definedfor the signaling message and therefore is a candidate for a signalingmessage for the event activity ReceiveOffer.

[0075]FIG. 6 proposes a solution to a further problem. In certainenvironments potential addressees are unique only within said certaindomains. Examples for such a situation are process instance identifiers,which are unique only within that set of process instances, which arederived from a common process model.

[0076] To cope with such situations it is suggested that the eventidentification specification comprises specifications, which, whenevaluated, allow to limit the scope of potential addressees to processinstances of a common process model. The specific embodiment 620 in FIG.6 allows to construe from one or more data elements of the signalingmessage (in this example the parameter businessProcessID—refer to FIG.4) an identifier of a process model. As a consequence only processinstances which are instantiated from process models with this construedidentifier are viewed as potential addressees; of course the otherspecifications within event identification specifications will furthernarrow and identify the concrete addressee(s).

[0077] An event within a process instance is uniquely identified via anactivity instance identifier. Thus an alternate approach exists for thespecification of the target of a signaling message. Said specificationis an alternate specification for the combination of PROCESS_INSTANCEand TARGET_IDENTIFICATION specification. FIG. 7 illustrates how such aspecification could look like. The keyword ACTIVITY_IDENTIFICATION 710identifies one or more fields within the signaling message to construe(even by a more complex expression) the identifier of an event activitybeing the addressee of the signaled event. In the current example, thefield EventId 720, which is part of the signaling message, is useddirectly to construe the event activity identifier representing saidaddressee.

[0078] At runtime the above specifications are used by the WEMS in thefollowing manner:

[0079] First the WFMS determines the structure of the signaling message.This requires inspecting all MESSAGE_DEFINITIONs for all eventactivities in all process models. If the structure of the signalingmessage cannot be determined, the WEMS assumes that the message is notan event-signaling message and takes other necessary actions.

[0080] Second, the WFMS determines the process instance that is thetarget of the signaling message.

[0081] Third, the WFMS determines the activity instance within saidprocess instance that is the target of the signaling message.

[0082] Fourth, the WFMS copies fields from the signaling message to thecontext of the process instance.

1. A computerized method for determining an addressee of a signaling request within a Workflow Management System or a computer system with comparable functionality (WFMS), said WPSM administrating a process-instance being the instance of a process-model (301) of a business-process and said method being further characterized by said process-model comprising at least one event-activity (300), and in a first-step said WFMS receiving (350) a signaling request, said signaling request providing a set of signal data elements (430); and said signal data elements not comprising any explicit specification identifying said process-instance or said event-activity as addressee of said signaling request; and in a second-step said WFMS determining whether said process-model is comprising an event-identification-specification (540) involving a subset of said signal data elements: and, in the affirmative case, evaluating said event-identification-specification to indirectly decide if said event-activity is an addressee of said signaling request; and, in a third-step said WFMS providing said signaling request to said event-activity as addressee.
 2. A computerized method for determining an addressee of a signaling request according to claim 1, wherein said event-identification-specification comprising a first-specification (542), which by evaluating is deciding if said process-instance is said addressee of said signaling request.
 3. A computerized method for determining an addressee of a signaling request according to claim 2, wherein said event-identification-specification comprising a second-specification (544, 720), which by evaluating is deciding if said event-activity of said process-instance is said addressee of said signaling request.
 4. A computerized method for determining an addressee of a signaling request according to claim 3, wherein said first-and/or said second-specification comprising a Boolean-predicate further involving data elements of a context of said process-instance.
 5. A computerized method for determining an addressee of a signaling request according to claim 3, wherein said second-specification (720) is construing from said subset of said signal data elements a first identifier to be compared to a second identifier identifying said event-activity for deciding if said event-activity of said process-instance is said addressee of said signaling request.
 6. A computerized method for determining an addressee of a signaling request according to claim 2, wherein said event-identification-specification comprising a fourth-specification (620), which by evaluating is limiting the scope of potential addressees to process instances of said process model.
 7. A computerized method for determining an addressee of a signaling request according to claim 1, wherein said event-identification-specification comprising a third-specification (536) to decide based on the type of said signaling request if said process-instance is said addressee of said signaling request.
 8. A system comprising means adapted for carrying out the steps of the method according to anyone of the preceding claims 1 to
 7. 9. A data processing program for execution in a data processing system comprising software code portions for performing a method according to anyone of the preceding claims 1 to 7 when said program is run on said computer.
 10. A computer program product stored on a computer usable medium, comprising computer readable program means for causing a computer to perform a method according to anyone of the preceding claims 1 to 7 when said program is run on said computer. 